A problem in the art of transmitting packets containing real-time-constrained information over internet protocol (IP) networks is the need to give each type of information the appropriate processing. In order to do this, it is necessary to know the type of information that is contained within each packet as it passes through the network at each point at which the packet will be processed. In particular, video, such as using Motion Pictures Expert Group (MPEG)-2 encoded video, cannot withstand dropped packets. Therefore, in processing streams of packets that contain MPEG-2 video, it is necessary to give priority to any MPEG-2 video streams over other streams which are less sensitive, or insensitive, to dropped packets.
Prior art techniques prioritize packets based on predefined criteria without actually ascertaining, e.g., by investigating the contents of the packet, that the packets actually contain MPEG-2 video. For example, a packet flow may be defined and it is assumed that all packets in that flow are MPEG-2 packets, and packets from that flow are treated as if they contain MPEG-2 packets without regard for their actual contents. A flow is often defined by specifying source and destination IP addresses for the flow, or by specifying the source/destination port address thereof.
Another prior art technique that is used to prioritize packets is based upon the so-called “type-of-service” (TOS) byte, which is part of the IP packet header. The TOS may be used to indicate a coarse prioritization, so that, for example, it is assumed that any packet with either a predefined value in the TOS byte, or a value in the TOS byte that is at least a predefined value, contains MPEG-2 video and is treated appropriately.
Because these prior art techniques do not actually investigate the contents of the packet to be certain that it contains MPEG-2 video, it is possible that packets that do not contain MPEG-2 video will be processed as if they contained MPEG-2 video. Provided that there is sufficient bandwidth in the processing system, processing these non-MPEG-2 packets, i.e., these fake MPEG-2 packets, as if they were indeed actual MPEG-2 packets is not a problem. However, in the face of limited bandwidth—and what system does not have limited bandwidth—processing these fake MPEG-2 packets as undroppable actual MPEG-2 packets unnecessarily consumes system resources. Furthermore, these prior art prioritization arrangements can be abused by an unscrupulous user who sets his flow, or TOS byte, to indicate that he is sending MPEG-2 video, when in reality he is not.
In addition, setting up the flows in an IP network—the flows being a static configuration that specifies fixed ports—requires administration and/or reconfiguration each time a flow needs to be changed, i.e., a) when a point to point connection changes one of its points, b) when a new connection is made, or c) the like. Note that each switch or processing unit through which an MPEG-2 video stream flows must be updated with the new flow identifying information each time a flow needs to be changed. Thus, there is a constant administrative burden due to the resulting flow churn.
Another problem that arises in prior art arrangements using the TOS byte to define a flow that is to contain MPEG-2 video is the need for all of switches or processing units through which the flow passes to agree to a common TOS byte value, or set of values, that indicate MPEG-2 video. Otherwise, some switches or processing units may not properly handle, e.g., may drop, the MPEG-2 packets. It is difficult in practice to arrange for such agreement, especially when the flow travels over multiple networks.